talked this out with @patrickhulce ... Here's the proposal:

1. We plan now for detections that won't be possible with js-lib-detector.
2. We rename our JSLibraries artifact to Technologies, and we could add more items to the array based on our own evaluation of the networkRecords, etc. (Like for stack packs for Fastly, Cloudflare, etc)
3. We retitle the current 'js-libraries' audit because it'll now include things beyond just js-libraries.
4. We use the definitions below.

stack pack definition:

stackPacks: [
  { 
      id: 'wordpress'
      title: 'WordPress',
      iconDataUri: 'data:image/...',
      requiredTechnologies: ['js:wordpressapi', 'core:wordpress'], // see 'type' and 'id' below.
      advice: {
        'unused-css-rules': 'Consider reducing, or switching, the number of [WordPress plugins](https://wordpress.org/plugins/) loading unused CSS in your page. To identify plugins that are adding extraneous CSS, ........',
        'uses-webp-images': 'Consider using a plugin/service that will automatically convert your uploaded images to the optimal formats.',
        // ...
      }
  }
}

Technologies artifact

interface GathererArtifacts {
  // ...
  Technologies: DetectedTechnology[]
}

interface DetectedTechnology {
  type: 'js', // basically the source of the detection. js is js-library-detector.. 
              // and 'core' is any detections custom defined in lighthouse's Technologies artifact.
  id: string //  if (type=='js') lib.npmPkgName || lib.icon. 
             //  if (type=='core') whatever we think is decent.
  name: string // the display-friendly name of the technology
  version?: string // any version data we have
  npm?: string // npmPkgName if it exists
}

sounds good to me, let me cleanup this PR to get comments resolved

We rename our JSLibraries artifact to Technologies

Unless we're renaming these "TechPecks", it seems like it's confusing to call this anything but Stacks? "Stack" is already super overloaded, referring both to entire stacks and also parts of the entire stack.

iconDataUri

we just say URL now :)

interface DetectedTechnology {
  type: 'js', // basically the source of the detection. js is js-library-detector.. 
              // and 'core' is any detections custom defined in lighthouse's Technologies artifact.

What is type communicating? If it's the type of stack, it seems like core needs to instead be more about the stack and not how it was detected. If it's how it was detected, it doesn't seem that important to have, but for debugging and whatever, maybe a different property name? (e.g. detector: 'js-library-detector', detector: 'core', etc)

If it's how it was detected, it doesn't seem that important to have, but for debugging and whatever, maybe a different property name? (e.g. detector: 'js-library-detector', detector: 'core', etc)

Yeah it's changed to now be how it is detected, so +1 to renaming to detector or something 👍

it seems like it's confusing to call this anything but Stacks?

K. That works for me. requiredStack: ['...', '...']

What is type communicating?

another +1 for type -> detector.

FYI : Submitted a pull request to include WordPress detection to the library-detector (since we still plan to use it for V1)

🎉 🎉

just a warning for those using file:./ and yarn, as far as I can tell yarn copies the directory into node_modules/, and then any changes you make to that directory after that aren't reflected when you run things.

I've been deleting the @lighthouse/stack-packs entry from yarn.lock and then running yarn again to force yarn to recopy the directory, but maybe there's an easier way :)

does --check-files help?